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ELECTRONIC IDENTIFIER STORAGE AND RETRIEVAL SYSTEM 

SUBJECT MATTER OF THE INVENTION 

1. Field of the Invention. 

5 The present invention relates to a system for storing and retrieving electronic 

identifiers, and, more particularly, an interactive system for creating and maintaining a 
searchable database of old and new electronic identifiers, such as e-mail addresses. 

2. Background of the Invention. 

10 Most Internet users have multiple e-mail addresses (e.g. 

austin@freshaddress.com ). These electronic addresses are unique ways of reaching an 
individual, but are not necessarily permanent throughout one's life. Electronic addresses 
change for many reasons, including when the individual moves, changes employers, or 
selects a different Internet service provider. Instead of changing or letting an address 

15 lapse, some people will maintain multiple addresses. For example, someone may obtain 
an address through school, add a personal address, and obtain an address from work. 
Still others maintain multiple Internet service providers to mitigate access problems, and 
each ISP typically yields at least one e-mail address. The result is that a single individual 
or entity may accumulate many addresses over time. 

20 When an individual changes his e-mail address, he must notify friends, relatives, 

and business associates of the new contact information. There are also numerous 
electronic services and businesses that need updating. Inevitably, not everyone is 
notified, and those who are not notified are left with an e-mail address that no longer 
functions or works — a "dead" address. When e-mail is sent to a dead address the sender 
25 typically receives a message informing them that the message was undeliverable, but not 
providing a current e-mail address for the intended recipient. Other old addresses may 
not be dead, but rather out of favor with its owner such that e-mail should not be sent to 
that address. 

The same problems exist for other electronic based identifiers. For example, 
30 such identifiers can include homepages having URLs with a unique second level domain 
name or a common second level domain name shared by many other individuals and 
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DETAILED DESCRIPTION OF THE INVENTION 
The present invention comprises a system which can be deployed as a web site on 
the Internet, having three primary components: registering (FIG. 1), searching (FIG. 2), 
and updating (FIG. 3). Through the use of the system, old and new electronic identifiers 
5 are interrelated so that a visitor to the system can find the preferred identifying 

information about a registrant with the system. While the embodiment described herein 
relates to e-mail addresses, the system could be readily adopted to accommodate other 
electronic identifiers, such as URLs, ICQ #s, and chat handles. 

10 Registration Process 

The registration component of the present invention is best illustrated in Fig. 1 . 
In this process, the registrant enters his old and new e-mail addresses into the system. 
Variations of the precise process should be obvious to one of skill in the art, and those 
variations are included within the scope of this invention. 
15 As a first step 1 0, the "soon to be" registrant must first enter his preferred address 

followed by a password. The preferred address may not be the only viable address for 
the registrant, but rather is the e-mail address he prefers others use to contact him. As a 
validity mechanism, the registrant must accurately retype the selected password. A 
password hint is also available in the preferred embodiment in case the registrant forgets 
20 his password in the future. Preferably, the system also checks to make sure that: the 
password is not contained within the preferred address; the hint does not contain the 
password; the password is not easy to guess; and the password contains a specified 
minimum number of characters. A typical interface is used such as a graphical button so 
that the registrant may indicate when he has finished entering the required information. 
25 Validation steps 15, 20, 25 are then performed to ensure among other things that: the 
preferred address conforms to the standard e-mail format 15; is unique 20 in comparison 
to other names in the system; and that the registrant has not already registered that e-mail 
address 25. 

Additional features of the system provide for privacy options (not shown) which 
30 are intended to reduced unwanted e-mails, including spamming. For example, 

registrants would be given the option to have their preferred address returned to a visitor 
as a graphic. Or, similarly, the system would require answers to specific questions about 
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allow each newly entered address to be marked as dead or current. Dead addresses are 
addresses which are non-functioning, and current addresses are functioning but are not 
preferred by the registrant to be used for e-mail by visitors to the system. Validation 
steps 40, 45, 50 are then performed to ensure that all e-mail addresses conform to the 
5 standard e-mail format and for other issues as described in conjunction with steps 15, 20, 
25 above. After these steps, a confirmation e-mail 55 may be sent to each e-mail 
address, whether current or dead for the purposes noted above with regard to the 
confirmation e-mail 30 described in conjunction with the preferred address. This process 
will be discussed in more detail below. 

10 Once the current and/or dead addresses have been validated, which may or may 

not include results from the confirmation e-mail step 55, the registrant is queried 60 for 
e-mail addresses of at least one entity to be contacted in the event that the registrant's 
entered information becomes outdated. The registrant may also be prompted to enter his 
own name so that the contact or contacts can receive a notification from the system. A 

15 simple validation step 65 is then performed to ensure that all entered contact e-mail 
addresses conform to the standard e-mail format. Preferably, confirmation e-mails are 
then sent to the enumerated contacts 70. Here too, the recipient, if so desired, may object 
to or otherwise modify the contact information received from the system. 

Having finished the complete registration process, the registrant is notified that 
20 he is registered with a preferred address; that he will receive a confirmation e-mail with 
information about the registration; and that he should update his registration where 
necessary. 

In another embodiment, the confirmation e-mail steps 30, 55, 70 may be launched 
near the completion of the registration process. Similarly, validation steps may occur at 
25 different times during the process. To maintain data quality, at least the preferred 

address is periodically sent e-mails by the system. In all cases, bounce-back or protest e- 
mail responses are monitored, so that the data can be handled as necessary. This is 
discussed further in conjunction with the periodic e-mail process described with FIG. 5 
below. 

30 In the event that one or more of the registrant's addresses are not unique in 

comparison to other names in the system, the registrant may be prompted to enter 
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is going to send an e-mail over the system. Finally, the system may indicate to the 
visitor the preferred address, the date of registration or last update by the registrant, or 
other information associated with the registration. 

If the preferred address is known by the system to be suspect, such as through a 
5 bounce-back to a periodic e-mail, the visitor may also be warned that the preferred 
address may not be accurate or functioning. In the event that the visitor knows the 
preferred address to be suspect, such as through a previous bounce-back to an e-mail, a 
mechanism may be provided for the visitor to self-report the suspect preferred address. 
In one embodiment, a graphical button will be provided so that the visitor can indicate a 
10 suspect preferred address. 

The searching of a particular record by a visitor may be stored as statistics for the 
registrant. The registrant may later visit the system and obtain the information which 
may include identification of the visitor and the date and time visited. 

In the event that the system found no match to the search query, an option would 
15 be provided to notify the visitor once the preferred address was known. Such an option 
would be made available to the visitor through typical graphical and textual interfaces, 
and would require the visitor to enter appropriate contact information. 

As a further feature, if the preferred address is not known by the system, a 
heuristic table is consulted. This table contains a list of unrecognized queries and the 
20 likely corrections. The table is generated by creating a list of common misspellings to 
commonly used domain names or changes to commonly used domain names. For 
example, if it is determined that a common misspelling of the domain name 
freshaddress.com is freshadress.com, then the table will refer to freshaddress.com for all 
appearances offreshadress.com. Similarly, if the provider of freshaddress.com changes 
25 all e-mail addresses to freshaddressinc.com, then the table would match those two 

addresses. If an entry is found in the table, the visitor is notified of his possible error and 
the suggested correction. The system may then prompt the visitor to perform a corrected 
query. 

30 Updating Process 

The updating process (Fig. 3) permits a registrant to change any part of his 
database information. To validate his identity, the registrant is first prompted 125 for his 
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When updating the addresses, the registrant is also provided the option to add 
textual or graphical features for existing or new addresses. In addition, if the registrant 
desires, some of the privacy features may be implemented to preclude unwanted e-mail. 
When completed, the registrant also has the option to forward any new preferred address 
5 to all contacts or any other list of addresses, including from an address book that the 
registrant may have running in conjunction with the system. 

To change passwords, the registrant is asked to enter his old password, his new 
password and a new password hint, and the registrant is asked to reenter his new 
password for confirmation. Processing modifications to these records are similar to step 
10 10 described above. 

To change contacts, the registrant is presented with his previously entered contact 
information including all existing contact e-mail addresses and a graphical button to add 
new contacts. As the registrant clicks on the item to be changed, text boxes or other 
known modification interfaces are made available. Upon acceptance by the registrant of 
15 the accuracy of the information entered, the information is validated, and confirmation e- 
mails 145 are sent as discussed above. 

Confirmation E-mails 

Confirmation e-mails, as illustrated in FIG. 4, are sent 30, 55, 70, 145 to every 

20 registered preferred, current, dead and contact address, as noted throughout this 
description, primarily as part of the registration process (FIG. 1) and the updating 
process (FIG. 3). Each mailing is tracked over a period of time, typically two days, to 
determine whether a bounce-back message is received 160 indicating that the 
confirmation was undeliverable. The system recognizes the difference between bounce- 

25 back messages and responses, including automatic replies. E-mails sent to current, 

preferred, and contact e-mail addresses are expected to arrive successfully. E-mails sent 
to dead addresses are expected to bounce-back. Thus, if an e-mail bounce-back to a 
preferred, current, or contact address is not received 165, the address is marked accurate 
170. For a dead address with no bounce-back, the address is marked as suspect 175 and 

30 is subject to further processing such as notification to the registrant of a potential 

problem. Similarly, if an e-mail bounce-back to a dead address is received 1 80, then it is 
marked accurate 1 70. Since a server may be down or an e-mail may bounce-back for 
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or a network of computers. For example, the system may be used in conjunction with 
commercial e-mail systems such as those offered by Microsoft (Outlook) or web-based 
e-mail systems such as Hotmail. As such, when the registrant sends an e-mail, the 
system will be searched and the e-mail address for the recipient (if a registrant) will be 
5 confirmed or updated before the e-mail is sent. 

Similarly, as shown in FIG. 6, target e-mail lists or e-mail address books may be 
forwarded 275 to the system for review of each of the target e-mail addresses 280. The 
review is similar to that undertaken during the search process noted above. However, 
with larger databases that are being reviewed, the system will either correct the actual 
10 information in the delivered database or provide a table of the delivered addresses and 
the preferred address for those in the system 285. An alternative is to have a series of 
bounce-backs sent to the system 290. The system culls the bounce-backs 295 for each 
address used in the failed e-mail. These e-mail addresses become the targets for the 
searching process described above. 
15 Additionally, a connection to the system may be provided in standard bounce- 

back e-mail messages so that the recipient of such a message can use the system to 
search for a preferred address. In a preferred embodiment, a link will be provided in the 
bounce-back message to a web site on the Internet where the recipient can use the 
system. 

20 Having described this invention in detail, those skilled in the art will appreciate 

that numerous modifications may be made thereof without departing form the spirit of 
this invention. Therefore, it is not intended that the scope of this invention be limited to 
the embodiment illustrated and described. Rather, it is intended that the scope of this 
invention be determined by the appended claims and their equivalents. 

25 What is claimed is: 
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8. The system of claim 7, wherein said electronic identifiers are e-mail addresses, 
and said confirmation process comprises sending an confirmation e-mail to each of said 
functioning electronic identifiers from said series of electronic identifiers, monitoring 
said confirmation e-mail for bounce-back messages or no response, and marking said 

5 electronic identifiers as suspect if a bounce-back message is received or accurate if no 
response is received. 

9. The system of claim 1, wherein said electronic identifier is an email address, and 
a plurality of e-mail bounce-backs are individually culled by the system to create said 

10 target e-mail addresses for said searching process. 

1 0. The system of claim 1 , further including a heuristic table having a list of 
unrecognized electronic identifiers and likely corrections, and said electronic identifiers 
provided during said registration process and said searching process are compared to said 

15 table, and said likely corrections are returned as a response to the visitor. 



WO 01/06497 



PCT/US00/19801 



(^STARt) 



1/6 

REGI STRATION 



PROVIDE INPUT SCREEN 
(REQUEST PREFERRED 
EMAIL ADDRESS 
CREATE PASSWORD 
CREATE HINT) 




IS INPUT 
INFORMATION 
SUFFICIENT? 



SEARCH 
DATABASE 




T 



IS EMAIL ADDRESS 
ALREADY 
REGISTERED? / 




SEND 
CONFIRMATION 
EMAIL 



T 



PROVIDE INPUT SCREEN 
(REQUEST ADDITIONAL 
CURRENT EMAIL 

ADDRESSES 
REQUEST DEAD 
EMAIL ADDRESSES) 



35 




40 



IS INPUT \N 

INFORMATION ) 

SUFFICIENT? / 



SEARCH 
DATABASE 



U^ 5 



Y X ARE EMAIL 

— < ADDRESSES ALREADY 
REGISTERED? 




60 



PROVIDE INPUT 
SCREEN 
(REQUEST FRIENDS' 
EMAIL ADDRESSES) 


\ 


65 

f f—^ 



/ IS INPUT \ 
( INFORMATION V*- 
\ SUFFICIENT? / 



70 



SEND 
CONFIRMATION 
EMAILS 




f 



( ^END^ ) 



55 



SEND 
CONFIRMATION 
EMAILS 



FIG. 1 



SUBSTITUTE SHEET (ROLE 28) 



WO 01/06497 



( jstart ) 



75 



PROVIDE INPUT 
SCREEN 



T 



IS INPUT 
INFO 
SUFFICIENT? 




SEARCH L^-g 5 
DATABASE 



PCT/US00/19801 



2/6 

S EARCHING 



90 



no 




DOES EMAIL 
ADDRESS EXIST 
IN DATABASE? 




N 




DISPLAY ERROR 






1 



-»-(^DONE^) 



95 



115 




IS ADDRESS A \ Y 

REGISTERED DEAD > — ► 

ADDRESS? 



DISPLAY 
PREFERRED 
ADDRESS 



^►(^DONE^) 



N 




100 



IS ADDRESS A \ y 

REGISTERED CURRENT 
ADDRESS? 



T 




DISPLAY 
PREFERRED 
ADDRESS 



\j 

^ DONE J 



N 



DISPLAY 
PREFERRED 
ADDRESS 

(dONE^) 



-105 



FIG. 2 



SUBSTITUTE SHEET WIRE 26) 

3NSDOCID: <WO 010R497A? I > 



WO 01/06497 



PCT/US00/19801 



3/6 

U PDATTNG 



f START J 



125 



PROVIDE INPUT SCREEN 
REQUESTING PREFERRED 
ADDRESS AND PASSWORD 



IS INPUT 
INFO 
SUFFICIENT? 



} 


Y 

r 


SIGN IN USER 
TO SECURE 
AREA 




f 


PROVIDE MENU 
OF UPDATE 
FUNCTIONS 



1 



SEND 
CONFIRMATION 
EMAIL OF ALL 
CHANGES 



SIGN OUT 
USER 



Q END ^) 




130 



J35 



J 40 



145 



FIG. 3 



3NSDOCID: <WO 0106497A2 I > 



SUBSTITUTE SHEET (BOLE 26) 



WO 01/06497 



PCT7US00/19801 



4/6 



CONFIRM A TTON ErMAILS 



165 



WAS IT 
EXPECTED TO 
BOUNCE? 



170 




MARK EMAIL 
ADDRESS 
ACCIJRATF 



(^START^) 

J 



SEND 
CONFIRMATION 
EMAIL 



-^30, 55, 70, 145 





160 



DID IT BOUNCE \ Y 
WITHIN X DAYS? 




175 



MARK EMAIL 
ADDRESS 
SUSPFCT 



180 




WAS IT 
EXPECTED TO 
BOUNCE? 



N 




170 



MARK EMAIL 
ADDRESS 



FIG. 4 



JNSDOCID: <WO 0106497A2 I > 



SUBSTITUTE SHEET {HOLE 26) 



WO 01/06497 



PCT/US00/19801 



5/6 

PERIODIC E-MAIL 



( ^start ) 



-200 



SEND PERIODIC 
EMAIL TO 
PREFERRED ADDRESS 



I 



205 



DID THE EMAIL 
BOUNCE BACK 
WITHIN X DAYS? 



N 



210 



MARK 
PREFERRED 
ADDRESS 
ACCURATE 



( jjoneT ) 



212 




ARE THERE OTHER 

REGISTERED 
CURRENT EMAIL 
ADDRESSES 



215 



SEND EMAIL 
REQUEST 



I 



220 




WAS THE EMAIL 
SUCCESSFULLY 
RECEIVED AND DID THE 
USER UPDATE 
PREFERRED ADDRESS? 




240 



L 



r- 

^ f 



225 




ARE THERE 
FRIENDS' 
EMAIL 
ADDRESSES? / N 



T 



230 



SEND EMAIL 
REQUESTS 



I 



WAS AN 
UPDATED 
ADDRESS 
PROVIDED? 



235 



N 



ADD 
ADDRESS TO 
USER'S 
RECORD 



-i 245 



MARK 
REGISTRATION 
SUSPECT 

(done) 



FIG. 5 



JNSDOCID: <WO 0106497A2 I > 



SUBSTITUTE SHEET (RULE W) 



WO 01/06497 



PCT/US00/19801 



6/6 

BUSINESS FRESHENING 



_T_ 



^START^) 



LIST OF ELECTRONIC 
IDENTIFIERS DELIVERED 
TO SYSTEM 




-275 



RETURNED 
EMAILS 
DELIVERED TO 
SYSTEM 



EACH ELECTRONIC 

IDENTIFIER IS 
COMPARED TO THE 
SYSTEM DATABASE 




T 



280 


EACH EMAIL 




PROCESSED AND LIST 




OF EMAIL ADDRESSES 




AND LIST OF 




ELECTRONIC 




IDENTIFIERS CREATED 



TABLE OF CONNECTED 

ELECTRONIC 
IDENTIFIERS CREATED 



TABLE DELIVERED 
TO BUSINESS 



I 



( ^DONE^ ) 



FIG. 6 



3NSDOCID: <WO 0106497A2 I > 



SUBSTITUTE SHEET (RULE 26) 



